[AIT-1226] Merge the AI Transport About and Why pages into one landing page - #3505

Two pages at the top of the AI Transport nav were doing overlapping jobs:
"About AI Transport" introduced the product, and "Why AI Transport"
argued for it. A reader arriving from marketing or from another product's
docs had to read both to get either answer, and each page repeated the
other's framing. Collapsing them puts the high-level content in one place
and lets the "Why AI Transport?" section sit above "Getting started",
where the question it answers actually gets asked.

The merged page keeps /docs/ai-transport, because that is the URL 26
inbound references already use as the product entry point, and moving it
would have put a redirect on the highest-traffic path into the section.

The page is written to answer necessity rather than comprehension. Two
founder calls in late July concluded that readers understood the product
and still could not see why they needed it before a V2, and that the
scale-oriented framing actively invited "nice to have". So the page opens
on the failure modes a reader already has, states that the threshold is
response duration rather than traffic volume, shows both seams that
change when retrofitting an application that already streams, and names
the constraints and dependencies adoption brings.

Several claims carried by the old pages are gone because the roadmap, the
feature pages, and the SDK do not support them: LangChain and native
model-provider integrations, human handover, two platform statistics that
appear nowhere else in the docs, and a publish-order guarantee that
message-ordering.mdx explicitly refutes for cross-region publishers.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The tradeoffs table hung data portability off webhook and Kafka egress,
which does not support it: those sources document channel.message, and
nothing says the append operations that carry a streamed response are
delivered outbound. Dropping the claim entirely was the wrong correction,
because database hydration does support it by a different route: an agent
that persists each completed run holds the conversation, since the union
of completed runs reconstructs it losslessly.

Gives that its own row sourced to database hydration, and leaves webhooks
and Kafka scoped to the analytics and audit use they are documented for.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review feedback was that the page read as machine-written: smartassy.
The style-guide checklist was clean, so the problem sat above it. Reading
it back, almost nothing was described and everything was argued. Every
section closed on a line shaped like a slide title, the same
this-not-that frame carried every paragraph, and plain verbs had been
swapped for more interesting ones throughout. Those are the tells, so
this strips them: the rhetorical triples, the objections raised only to
be knocked down, the reveals, and the closers.

The argument is also now in two parts rather than one table mixing both.
The first covers what moving off HTTP streaming fixes, which is the same
product with the failures taken out: resume, second device, reload, stop,
concurrent turns, agent restart. The second covers what the session adds
because it is an Ably channel with a conversation tree over it, and none
of which HTTP streaming can express at all: branching and regenerate,
agent and client presence, shared live state, steering, approval gates,
chain of thought.

The agent sample was not runnable, since the streamText result it piped
was never defined. It is now a complete handler, with the body in
try/finally because session.end closes a still-open run rather than
leaving observers stuck on streaming.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>